This seems to only happen on windows, I could not reproduce it on linux. It's strange that this media file is triggering a js bug, I won't pretend to know what's going on. Steps to reproduce: - Open browser - Play attached test case

Considering the crashing function and the output of |hg blame UbiNodeDominatorTree.h|, needinfo-ing fitzgen.

I can't reproduce on OSX, either. But, given that: > WARNING: Stack unwind information not available. Following frames may be wrong. And that the test case and STR has nothing to do with heap snapshots and dominator trees, I think this is a corrupt stack or at least bad stack capturing. I will try and reproduce under windows.

Seems to be some hand-rolled assembly deep in third party media code, which I am completely unfamiliar with. ni'ing some folks who might know more.

The point in the screenshot is definitely in media code. But according to the log, isn't the crash here? MSVCR120!memcpy+0x2a: 7319f20c f3a4 rep movs byte ptr es:[edi],byte ptr [esi] ?

Third party media code you say? ... Adding some media folks. Hopefully they can help or add the correct people.

Better to NI. Chris, this is crashing when playing a particular mp4 on windows.

I grabbed a better stack trace and it looks like this is a dup of bug 1232330. VCRUNTIME140!memcpy+0x4e xul!mozilla::layers::MappedYCbCrChannelData::CopyInto+0x48 xul!mozilla::layers::UpdateYCbCrTextureClient+0xd7 xul!mozilla::layers::ImageClientSingle::UpdateImage+0x366 xul!mozilla::layers::UpdateImageClientNow+0x32 xul!RunnableFunction<void (__cdecl*)(mozilla::layers::ImageClient *,RefPtr<mozilla::layers::ImageContainer> &&),mozilla::Tuple<mozilla::layers::ImageClient *,RefPtr<mozilla::layers::ImageContainer> > >::Run+0x10 xul!MessageLoop::DoWork+0x1ac xul!base::MessagePumpDefault::Run+0x1a4 xul!MessageLoop::RunHandler+0xa4 xul!MessageLoop::Run+0x3f xul!base::Thread::ThreadMain+0xb8 xul!`anonymous namespace'::ThreadFunc+0x9 KERNEL32!BaseThreadInitThunk+0x24 ntdll!__RtlUserThreadStart+0x2f ntdll!_RtlUserThreadStart+0x1b